#2953 had a twin one tier over, unreported. Found by checking whether the kind:'html' path shared the root cause — it does, with a worse blast radius.

Measured, not inferred

A probe rendering <flex><object-kanban object="showcase_project" /></flex> as a kind:'html' page, with object-kanban registered lazily (exactly how apps/console registers it):

BEFORE_LOAD >>> HTML page failed to compile (2)
                <object-kanban> is not an allowed component
                <object-kanban> is not a known component
AFTER_LOAD  >>> HTML page failed to compile (2)      ← after the loader resolved
KANBAN_RENDERED >>> false

Root cause, and why it's worse here

getJsxManifest() built the whitelist from getAllTypes() + getConfig() — both loaded-only, same as #2953. So a registerLazy()'d block was rejected as unknown, load-order dependently.

Two things make this worse than the react tier:

1. The whole page dies, not one block. A compile diagnostic fails the page, so one <object-kanban> anywhere in the source replaced everything with an error panel — the <flex> wrapper included. In the react tier a missing block cost one identifier.
2. It never recovered. layoutElement was memoised on [schema, pageType] with no registry signal, so the cached error panel outlived the plugin actually landing. Broken for the rest of the session.

Also spotted on the way: getJsxManifest()'s cache key was the type count. One registration plus one unregistration leaves the count untouched while the set changed.

The fix

Three lazy-aware reads on ComponentRegistry:

getAllTypes() and getConfig() keep their loaded-only meaning ("what can render right now" / "can I render this") and now document it — getConfig()'s callers read .component off it, and a stub has none.

getJsxManifest() builds from the new reads; PageRenderer subscribes to the registry so a page that could not compile retries when the registry grows. Only the kind:'html' branch acts on that tick — every other branch rebuilds the same element type with the same props, which React reconciles in place, as react-page-state.test.tsx (#2984) pins.

On the strictness tradeoff

A stub has no inputs yet, so its props surface as unknown-prop warnings rather than errors: the page compiles and renders, and the inner SchemaRenderer triggers the loader and swaps in the real block.

That is the same call made in #2979 for the manifest generators, pointing the other way — and deliberately so. The runtime whitelist should be permissive, because the alternative is the whole page failing over a block that is genuinely part of the app. The build-time artifact must be strict, and assertFullyLoaded enforces that sdui.manifest.json is generated with every plugin eagerly loaded. So authoring-time prop validation keeps its full inputs; only the in-browser render path relaxes.

Tests

• lazy block no longer takes the page down;
• a late registration recovers the page;
• negative control: a tag nothing has registered is still rejected. Admitting stubs must not turn the whitelist into "anything goes" — that whitelist is what keeps a parsed page from rendering arbitrary tags.

The first two fail against the old page.tsx; the control passes throughout. Plus 6 unit tests for the new registry reads, including that getVersion() moves where a count would not.

Verification

• Full suite: 701 files passed | 1 skipped, 8234 tests passed | 24 skipped.
• turbo run type-check: 76/76.
• lint on core / components: 0 errors.
• changeset:check: clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01N4mrr1ihhwnfEHFSWmGoMp

Generated by Claude Code